Queue bank repository and method for sharing limited queue banks in memory

ABSTRACT

In a computer system a system of exchanging tokens for queue banks is created that permits a requestor to directly specify which queue bank is wanted. Only the desired queue bank is withdrawn from a queue bank repository to accomplish this and no sorting or FIFO handling of queue banks is needed. The system uses a schema similar to a coat check room, where the requestor is given a token when the requestor wants to deposit a queue bank into the queue bank repository. The queue bank repository returns the queue bank when the token is returned by the requester. In its most efficient form, two machine-level instructions handle the entire operation, a withdraw instruction and a deposit instruction.

This patent document contains material which is subject to copyrightprotection. The copyright owner has no objection to the facsimilereproduction by anyone of the patent disclosure, as it appears in thePatent and Trademark Office patent files or records, but otherwisereserves all copyright rights whatsoever.

BACKGROUND OF THE INVENTION

1. Field of the Invention

This invention relates generally to computer systems and processestherein for handling a large set of items with a finite memory resource,and particularly to managing access to said large set of itemsefficiently and preferably without copying said items.

2. Background Information

“SYSTEM ARCHITECTURE FOR IMPROVED MESSAGE PASSING AND PROCESSSYNCHRONIZATION BETWEEN CONCURRENTLY EXECUTING PROCESSES” (ISSUED Feb.22, 2000 U.S. Pat. No. 6,029,205) describes a system for coordinated useof messages in a computer system that eliminates the need for copyingmessages using queues. (This referenced patent application is herebyincorporated hereinto in its entirety by this reference.) That inventionworks well for ordered lists of messages, either first-in-first-out orlast-in-first-out. However, that invention does not solve the problem ofhow to accomplish its objective in a highly efficient manner so as toavoid the slow process of wading through (physically reviewing) all theentries in a queue to find the unordered data or message of interest.The instant invention, in contrast, has applicability preferably insystems which do not require copying of messages as described in theabove-referenced patent, but that can be applied more broadly to anysystem in which a great many items are in a queue and rapid access toparticular items is desirable.

In order to set forth the context of this solution, it is useful tofirst describe several general concepts.

“Processes” are the most widely used unit of computation in computerprogramming and computer systems. Much of the work of an operatingsystem of a computer is to provide an environment in which applicationprogrammers can define processes, execute them, and generally controltheir behavior. A process is a unit of computation. The action of theunit of computation is described by a set of instructions executed,typically sequentially, on a computer, using a set of data associatedwith the process. The components of a process are the program to beexecuted, the data on which the program will execute, resources requiredby the program (for example, memory), and the status of the execution.For the process to execute, it must have a suitable environmentincluding an engine for executing the program, memory for storing theprogram and data, and status information indicating the progress of theprocess. In contemporary computer systems, individual applicationprograms may be implemented as a set of processes. These processesusually must be able to share information and/or synchronize theiroperation. There are a number of design strategies to allow multipleprocesses to communicate with one another.

“Banks” are contiguous regions of address space, to which processes maybe granted visibility and access by the operating system and hardware.Banks are composed of one or more pages, each of which is a small,contiguous area of storage. The pages comprising a bank need not bephysically contiguous to each other. Generally, all pages of a bankshare such attributes as accessibility. If a bank is designated to holda queue or data that can be queued, it may be called a queue bank.

“Queues” are parts of a computer memory, which contain a group of items,each of the items containing some information of use to at least oneprocess or program. A queue bank may contain a number of queues. Eachqueue may also be its own bank. Queues are organized as lists, with twoends, which may be called a head and a tail, top and bottom, or frontand back. Items may be put onto or retrieved from a queue only from oneof these polar ends or the other, and the items are always organized ina sequential list form. Thus items can be organized to provide“First-In-First-Out” (FIFO) access, or Last-In-First-Out (UFO) access tothe items on the list. Accordingly, to get to an item in the middle ofthe list, one cannot do so without first taking all the items of whichare either ahead of the sought-for item, or all those which are behindthe sought-for item in the Queue's internally organized list.

It should also be noted that Queues may identify or be an ordered listof queue banks, thus leading to the concept of cascading queues, orqueues of queues, or nested queues. A Queue may be composed of a set ofqueue banks, each one of which in turn may be composed of a queue, whichin turn may be composed of a list (or set) of items. We prefer to thinkof a queue as one queue bank; the items on the queue may also be queuebanks with each item queue bank linked in a list of items of the queue.Too, a queue bank may be a single queue of a set of items; or a queuemay be composed of a set of queue banks, one of which is just a set ofitems; and a queue may be composed of a set of queues which in turn arecomposed of a set of queues which in turn are composed of a set of queuebanks which in turn are composed of queues which are in turn eachcomposed of sets of items. Note that an “item” can be an event or aqueue bank. It is believed that these few examples sufficiently describethe potential for possible organization of queues and queue bankswithout being exhaustive.

In the above-referenced and incorporated patent, U.S. Pat. No.6,029,205, the requirement to pass control over queue items in anorganized way between multiple processes was considered, and a solutionto that problem described. However, where the number of queues and queuebanks is limited, either by available memory space, process constraints,or for other reasons, a solution to a new problem of accomplishing sucha result in a limited environment must be found. An additional inherentproblem is present where rapid access to the proper queue bank or queueis needed.

These problems become particularly acute in large-scale transactionprocessing systems particularly, where a single process has access to alimited number of queue banks and also is limited in its time availableto get to the item in the queue it needs. However, the solutionsdescribed herein may be used in other data processing, computer system,and communications system contexts as the need arises.

The solution should be applicable to multi-processor systems forcooperative processing, and to use in shared memory systems usingmultiprocessing systems. It should be applicable as well tomultiprogramming systems, all without undue experimentation beingrequired, once the concepts presented herein are understood.

A discussion of message-based interprocess communication mechanisms ishad in the above referenced U.S. Pat. No. 6,029,205 and is not repeatedhere; however, it is important to note that such systems are targetsystems for application of the solution of the instant disclosure. Inthe referenced patent, messages, whatever they may be or whatever datathey may contain, are passed in queue banks. Thus, queue banks may bethe message, the queue to which a message queue bank is enqueued, thequeue to which a queue containing queue banks is enqueued, or any levelof cascading of queue banks in queues.

An important limitation on message passing systems where the sending andreceiving processes are prevented concurrent access to the message isthe necessity of one or more iterations of copying the message data fromone block of memory to another in order to pass the data betweenprocesses. This copying is used in some systems to ensure that thereceiving process obtains an incorruptible message. Such message passingsystems use additional memory and limit overall system performancebecause of the time and resources used copying message data. Thenegative impact on performance of the message copy is insignificant forsmall messages. However, the cost of the message copy grows linearlywith the size of the message. Too, the number of messages being copiedweighs on the system resources. When the messages passed betweenprocesses become very large, such as is the case for large filetransfers occurring in file transfer, graphics, and multimediaapplications, system throughput suffers. The transfer of such messages,from 10,000 bytes for low-resolution monochrome images to 10,000,000bytes for high-resolution E-size graphics, places a severe strain on thecomputer system's ability to provide output to an end-user in a timelyfashion. Eliminating the need to copy message data for communicationbetween concurrently executing, cooperating processes while providingadequate message data security such as is provided by U.S. Pat. No.6,029,205 is important. It is also important that efficient use oflimited queues described in the instant document be available forsystems in which copies of messages are not made.

Too, when there is a finite resource, such as a limited number of QueueBanks, a system which allocated them would cut off requesting processesfrom acquiring rights to new Queue Banks since there were no more, andthe invention herein provides resolution for this difficulty as well.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is a heuristic block diagram of a type of computer system inwhich the invention can be used.

FIG. 2 is a block diagram of a queue bank.

FIG. 3 is a block diagram of a queue.

FIG. 4 is a block diagram of a nested queue.

FIGS. 5A, 5B and 5C are block diagrams of process states wherein aclient process is operating together with a queue bank repository inaccordance with the invention.

FIG. 6 is a flow chart of the process of a preferred embodiment of theinvention.

FIG. 7 is a depiction of the instruction apparatus used in the preferredembodiment of the invention to initiate the two queue bank repositorymanagement functions: deposit and withdraw.

SUMMARY OF THE INVENTION

An architectural element for the organization and use of queues providesa system level facility to store and to find needed queue banks,elements of a queue or other queues, quickly and in the context of acomputer system, efficiently. In the preferred embodiment a pair ofhardware instructions “deposit” and “withdraw”, are used to manage thisarchitectural element that we call a Queue Bank Repository (QBR). Aprocess “deposits” a queue bank to the QBR, a Queue Bank RepositoryManager (QBM) finds a place in the QBR for the queue bank reference fromthe available portion of the QBR, removes the queue bank from the clientprocess's address space, and returns a token to the process. Later, theprocess “withdraws” the queue bank by giving the QBM the token, the QBMaccesses the queue bank reference associated with the token, returns theplace that the queue bank reference occupied in the QBR to the availableportion of the QBR, and returns the requested queue bank to theprocess's address space. The QBR is preferably formed as a group ofmemory location references which can direct an inquiring process to aneeded queue bank immediately in exchange for a token (this isaccomplished in the preferred embodiment with a “withdraw” instruction).Or, the QBR can give a token to such a process when the process isseeking to store data regarding the location of a queue bank in the QBR,whereupon the QBR sets a reference to the queue bank identified to thetoken it has given to the process (this is accomplished in the preferredembodiment with a “deposit” instruction).

A Queue Bank is a unit of storage visibility in the system. In thepreferred embodiment, queue banks have the attributes to work with queuebank repositories. It is possible to define or name other “ranges ofaddress space and the data contained in them” to have the similarattributes of passed messages (e.g., serially shared—appears to oneprocess at a time—but not concurrently shared) that can also operatewith QBRs as defined in this application.

The term “token” as used throughout this application means a datum thatcan include, but is not limited to, a pointer, offset, or entry indexthat permits a QBM to identify the place occupied by the queue bankreference in the QBR.

The QBM means the functionality that keeps track of a deposited queuebank reference, returns a token for the deposited queue bank reference,accepts a token for a withdrawal of a queue bank, returns the assodatedqueue bank to the visible address space of the withdrawing process,manages the available space within the QBR, handles QBR full condition,and handles invalid tokens. In the preferred embodiment, the QBM is thecombination of the “deposit” and “withdraw” instructions.

Thus, for example, a process has put some data into a queue bank, butcannot retain control over it for some period of time while it needs towork on some other thing, so it relinquishes the queue bank to the QBR,in exchange for a token. When the process wants to use the data in thequeue bank again, it returns the token to the QBR, which returns thequeue bank it has stored in exchange for the token.

This provides an improvement over systems which needed to access a queueto find other queues or memory locations for finding data, since it isunnecessary to review each entry in a queue to find out if thesought-after entry is in the queue.

In order to provide a simple analogy, the inventive QBR system works ina manner similar to a coat-check room. A process (like a coat ownerwishing to store a coat) needing to store a queue bank for a token inexchange from a queue bank repository management process (the coat-checkattendant process) that manages the queue bank repository. Therepository manager hands out tokens in whatever order It wishes andcannot hand out tokens when it has no more left in the “basket”. Whenthe process which received a token in exchange for storing the queuebank it would need later (or the coat owner) returns the token, therepository manager returns the queue bank to the owner and the token tothe basket.

It is most likely that a single process uses the QBR for multiple uses,or for multiple users of the QBR. A single process can have multipleprocesses within the single process, too, which can all use the QBR.Also, the QBR could be used to pass messages, if desired, amongprocesses.

The QBR is managed through the use of machine-level deposit and withdrawinstructions in the preferred embodiment. Such instructions or theirequivalent should be executable on any processor, and emulation orsoftware implementation of the instructions is, of course, alsoacceptable for managing the QBR. The equivalent functions could beimplemented in high-level languages although the efficiency of thesystem would necessarily be reduced. Additional features can be added asdesired as well.

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS. I. FunctionalOverview of a Preferred Queuing Architecture

A Queuing Architecture is implemented in the preferred embodiment as animprovement to the 2200 Series computer systems commercially availablefrom Unisys Corporation, and described in the previously mentioned andincorporated U.S. Pat. No. 6,029,205. While this invention can be usedin other systems as will be apparent to one of skill in this art, thepreferred embodiment use is in the system for which this invention wasfirst designed and which is described in detail here. FIG. 1 is a blockdiagram of such a 2200 Series computer system. The Computer System 10includes one or more instruction Processors (IPs) 12, each IP having itsown First Level Cache 14. The IP executes instructions obtained from theMain Storage Unit 16 via other levels of caches 17 and/or StorageController 18. The First Level Cache 14 provides for the acceleration ofdata and instruction fetches for the IP 12. Although only oneinstruction Processor and First Level Cache are shown, multipleinstruction Processors and First Level Caches could be configured. Theremay be multiple levels of cache. “Higher” levels of cache may be shared.“Lower” levels of cache may be private. The invention described hereinmay function with any known cache stucture. The Main Storage Unit 16provides the internal mass memory capability for the system. The otherlevels of cache 17 and Storage Controller 18 control access to the MainStorage Unit and accelerate the data from the Main Storage Unit into theinstruction Processors. Other components of the system include one ormore input/Output Processors (IOPs) 20, 20′, each IOP having one or moreChannel interfaces (CH) 22, 24, 22′, 24′, respectively. The Channelinterfaces may be connected to peripheral devices such as magnetic diskdrives, magnetic tape drives, 1o printers, other computer systems, etc.The IOPs 20, 20′ interface the I/O channels through an I/O Bus 26 to theI/O Bridge 28. The I/O Bridge 28 is coupled to the Storage Controller18. (It should be noted that this embodiment hardware is just one ofmany useable with this invention. The I/O Bridge is not required to beconnected to any particular level of cache.) Because of the relativespeed differences between the IOP 20, the I/O Bus 26, and the Channelinterfaces 22, 24, one IOP 20 may service multiple Channels, typicallyeight or sixteen Channels per IOP. Individual Channels contain interfacecircuitry for each Channel and the connections necessary for Channelcables to peripheral devices (not shown). Power Supplies 30 are providedto supply electrical power to the system. The System Control Facility 32is a maintenance and system control unit for initializing the system andthe reporting of fault conditions. Certainly other designs of computersystems can be employed for use with this invention as will be apparentto one of ordinary skill in these arts; however, the one described isthe one currently used.

The preferred embodiment has a set of hardware queuing instructions(which become a part of the instruction set architecture of the 2200Series computer system) and related Operating System (OS) Executive(Exec) services to provide a protected message passing and processsynchronization mechanism. It is contemplated that the present inventionmay also be implemented in the instruction set architectures andoperating systems of other computer systems, or even at higher levels ofabstraction by application processes if desired. The U.S. Pat. No.6,029,205 supports the passing of large binary objects or any otherinformation shared between processes in a shared memory system and usesqueues to eliminate the need for data copying between concurrentlyexecuting, communicating processes within the computer system. In othersystems, copying of messages between processes is required in order toprovide adequate protection of the messages passed. (“Messages” are anyinformation passed internal to the system.) When the messages passedbetween communicating processes are small, the overhead for the messagecopy is insignificant. If ownership of the message is passed instead,the need to copy the message between subsystems or processes is negated.Additionally, in U.S. Pat. No. 6,029,205 patent's system there is noneed to introduce scrubbing or clearing of residual data. It may benoted that queuing has a “security” benefit in that when a message isqueued, the originator no longer has access to the data space which itqueued. From passers to receivers, serial access by each process is thusguaranteed.

It should be noted that the queuing entity cannot access what it queued.A process has access rights or access privileges to a queue. In thepreferred embodiment, when the process enqueues a Queue Bank to a queue,the Queue Bank disappears from is the process's address space. If theprocess has both enqueue and dequeue privileges to the same queue, thenthe process could enqueue a Queue Bank (make it disappear from itsaddress space) and then dequeue (eventually obtaining the same QueueBank which was just described as enqueued). When dequeued, the processhas made the Queue Bank appear in its address space. Likewise, a processhas access to a Queue Bank Repository (or more than one). The types ofaccess a process may have to a QBR would be “no access,” “depositaccess,” and/or “withdraw access” as may be desirable for the particularprocess). In the common situation, the process will have both depositand withdraw access because the process will be keeping the QBR foritself. (Of course, variations are available to pass information betweenprocesses and so forth.) To reiterate, when a process deposits a queuebank, it gives up visibility to the queue bank, and when it withdrawsthe queue bank, the process regains (or obtains) visibility of the queuebank; in a manner analogous to the access of a process to enqueued anddequeued queue banks. When withdrawing, the QBR need not put the queuebank into the same process address space that it occupied when theprocess deposited the queue bank.

In the preferred embodiment, processes communicate with each other inthe system by using commonly accessible queues to pass ownership of aqueue bank. Thus, the conceptual model for data transfer is pass byreference, not pass by value. A queue client process places entries orevents on a queue. A queue server process receives entries or events. Anentry contains a message passed between a client and a server over thequeue. The message consists of data or control information. The formatof the message is not inherent to the Queuing Architecture. Rather, themessage complies with the protocol contracted between clients andservers. An event is an indication that a condition known to both theclient and server has occurred, but which contains no message. Thus, anevent works as a synchronization mechanism between processes.

This architecture reduces the system overhead instruction path lengthfor the context switching of processes by providing an efficient processsynchronization mechanism. Instruction path length is the number ofinstructions (related to processing time) for executing a particularcode (or decision) path through a computer program. System overheadinstruction path length is the path length attributable to systemoverhead, not for direct application program use. The instruction pathlength of a process deactivate/activate sequence using the preferredembodiment of the present invention is less than the equivalentoperation using existing process synchronization mechanisms. Thesesavings are realized because the functions performing the context switchare executed in the preferred embodiment system, directly inhardware/microcode rather than by interrupting the operating systemsoftware (which in the preferred embodiment is the Unisys Corporation“Exec”) for handling, and also by eliminating the need to search througha list of active processes potentially waiting on an event. Further,once the “Exec” (or other operating system) establishes the accessrights processes have to queues within their respective domains, nofurther software checking of rights is needed. However, processes cannotaccess queues unless granted enqueue or dequeue (or both) rights to thequeue. The hardware instruction can check the rights of the executingprocess for the addressed queue. In the existing communications programused by 2200 Series computer systems, message bunching is used toamortize instruction path length over several messages. The presentinvention also eliminates the need for message bunching, therebyimproving message latency time in systems and situations that mayotherwise require message bunching. This advantage is important forapplication program environments where the response time requirementsare measured at machine speeds (e.g., a few milliseconds for a filetransfer).

To reiterate, when a message is enqueued, the message is removed fromthe client process's visibility. This prevents the client process fromoverwriting the message, thereby providing the server process with asecure message. Hardware access checks, which may use a standard lockand key mechanism, are preferably employed to prevent unauthorizedaccess to the queues. This provides message protection within thisarchitecture.

The invention described in U.S. Pat. No. 6,029,205 cited above, definesfour new instructions for hardware support of message passing andprocess synchronization. These instructions encompass the actions ofplacing an entry or event on the head or tail of a queue, receiving anentry or event from a queue, and forcing a process deactivation to waitfor an entry or event. The Enqueue instruction either adds an entry tothe tail of a queue, or, if so specified for a queue, adds an entry tothe head of a queue, or, if so specified by the programmer, places anevent on a queue. The Enqueue to Front instruction either adds an entryto the head of a queue, or, if so specified by the programmer, places anevent on a queue. The Dequeue instruction removes an entry from the headof a queue, if one exists. The Dequeue Or Wait instruction eitherremoves the entry from the head of a queue, if one exists, or detectsthat an event has been placed on the queue, or if the queue is empty(i.e., it has no entries or events), causes the active process executingthe instruction to deactivate until an entry or event is placed on thequeue. Therefore, in order to access any information through thisqueuing architecture, one must, without the invention described in theinstant document, Dequeue through an entire queue until the informationsought is found. Many other computer architectures require similarprocessing and can be similarly enhanced by use of this invention.

A. Basic Queue Structure

A Queue is the conceptual model used by the invention described in theabove-referenced U.S. Pat. No. 6,029,205 and which can be used in othercomputer systems to attain improved message passing and faster processsynchronization between processes. A Queue in the preferred embodimentconsists of one Queue Header and zero or more Queue Entries. The objectmaking up each element in the Queue is called a Queue Bank. A Queue Bankis a unit of storage visibility in the system. Queue Banks are units ofstorage visibility used as either Queue Headers, Queue Entries, or both.Queue Banks preferably reside in some memory like Main Storage Unit 16.A Queue Bank is comprised of two parts, a Control Area for controlinformation, and a Text Area for message data. A Queue Bank isreferenced and described by a Queue Bank Descriptor (QBD). FIG. 2 is adiagram of the format of a Queue Bank. In the preferred embodiment, theQueue Bank contains a protected 256-word Control Area 33, which containsthe queue links and various queue controls, and a 1- to 262,144-wordText Area 34, used to hold data specific to the queuing protocol used.The size of these fields are chosen because they are employed with thepreferred embodiment, but clearly, different sized fields would beappropriate for different computer systems with which this invention canbe used. The number of words in the Text Area used is dependent on thesize of the data being passed in the message. This size is preferablyspecified by an Upper Limit field in data for handling the message. AQueue Bank Descriptor (QBD) 35 is used to describe a Queue Bank. A BankDescriptor is a basic storage structure used for managing the addressspace in a computer system, but any virtual address organization wouldbe acceptable for use with the invention. Thus, in the preferredembodiment, the virtual address is a 36-bit word identifying the name ofa bank in which the address lies and the position of the address withinthe bank. (Using any virtual address system the address would identifywhere the Queue Bank is located.) A bank name could be used to identifythe Bank Descriptor that describes the bank.

For each queue, one Queue Bank acts as the Queue Header. In the QueueHeader, a Head Pointer and a Tail Pointer address the head and tailQueue Entries respectively. A Count is included in the Queue Headerwhich stores the number of Queue Entries currently enqueued. In eachQueue Entry, a Next Pointer points to the next Queue Entry in the Queue.In some situations, the contents of the Next Pointer, Head Pointer, andTail Pointer may be architecturally undefined. FIG. 3 is a diagramillustrating a sample Queue. The Queue Header 36 describes a Queue withfour Queue Entries labeled 37, 38, 40, and 42, respectively. Executionof an Enqueue instruction to this Queue Header 36 will add a Queue Entryto the tail of the Queue (unless a forced Enqueue to the head of thequeue is indicated in the Queue Header). The new Queue Entry 5 (notshown) will be pointed to by the Next Pointer 44 of Queue Entry 4 42,and by the Tail Pointer 46 of the Queue Header 36. Execution of aDequeue instruction based on this Queue Header 36 will retrieve QueueEntry 1 37, redirecting the Queue Header's Head Pointer 48 to point toQueue Entry 2 38. Execution of another Dequeue instruction will retrieveQueue Entry 2 38, and so on.

B. Hierarchical Queuing

To accommodate messages larger than can be placed in a single Queue Bankand certain order-critcal protocols, the Queuing Architecture supportshierarchical queuing. With hierarchical queuing, one queue can beenqueued and dequeued as a single entity on another queue. To supporthierarchical queuing, all fields relevant to both Queue Headers andQueue Entries are included in all Queue Banks. FIG. 4 is a diagramillustrating the concept of hierarchical queuing. In the example shownin FIG. 4, there are two Queues. Queue A, defined by Queue Header A 50,has four enqueued Queue Entries, A1 through A4, labeled 52, 54, 56, and58, respectively. Queue B, defined by Queue Header B 54, has threeenqueued Queue Entries, B1 through B3, labeled 60, 62, and 64,respectively. Queue Header B 54 is also Queue Entry A2 54 on Queue A.Queue B is enqueued to Queue A by executing an Enqueue instruction witha Queue Entry of Queue Header B and a Queue Header of Queue Header A.

II. Queue Bank Repositories and Their Use.

An illustration of the typical functioning of the QBR is found in FIGS.5A-C, wherein the client process 71 a-c interacts with a queue bankrepository manager (QBM) 72 a-c by passing tokens and queue banks backand forth between them.

In the preferred embodiment, the QBM is actually the operation of twohardware level instructions, deposit and withdraw. These instructionsare illustrated briefly in FIG. 7 as instructions A and B respectively,showing that a very small portion of the instruction 201 and 202 arerequired to indicate whether the instruction is a deposit or a withdrawinstruction. The rest of the instruction 102 or 104 would indicate whichQBR and either the queue bank or token. The first part of theinstruction words 101 and 103 preferably indicate what class ofinstruction this deposit A or withdraw B is. The deposit instructionallows the executing process to place a specified queue bank into therepository, receiving a token in exchange. The queue bank is removedfrom the address space of the executing process as part of thisoperation, thereby allowing use of that portion of the address space forother program purposes. The token returned by the deposit instructionmay be utilized subsequently by the withdraw instruction, which uses thetoken to retrieve the previously deposited queue bank from therepository, and restores it to the address space of the executingprocess, not necessarily in the same location from which it wasdeposited. Software processes can clearly handle this function as one ofordinary skill can show without undue experimentation upon review of theconcepts here within.

The QBM is responsible for also transferring tokens or queue banks fromthe header 731 a-c of the QBR 73 a-c and for being able to read from theheader 731 a-c which queue bank repository entry within the QBR isavailable next. (The QBR 100 a-c is illustrated as formed of the twocomponents QBM and QBR for convenience, and it is understood thatsoftware and/or hardware architects may employ these concepts in formsthat appear superficially different but which contain thecharacteristics described and taught herein).

Generally, the QBR can be described as any set of available entries,implemented as a linked list in the preferred embodiment. Also, entriesthat are in use (by a process) are not in the set of available entriesof the QBR. Thus, in the preferred embodiment when the depositinstruction operates, it removes an entry from the set of availableentries and fills it with a reference to a queue bank which the processsurrenders. Similarly, when a process, submits a token, the withdrawinstruction operates to restore visibility, in the address space of theexecuting process, to the queue bank represented by the surrenderedtoken (a reference to which in the preferred embodiment will be found insection 104 of the heuristic instruction word B of FIG. 7). The withdrawinstruction also makes that token available again in the set ofavailable entries. (Thus, one of ordinary skill in this art willrecognize that with respect to the preferred embodiment, a QBM is aheuristic function, being merely the operation of these two hardwareinstructions. Nevertheless, the use of such a function is important todescribe the operation of the invention appropriately for alternativeembodiments.)

In one preferred embodiment, before a process can issue deposits orwithdrawals, the process is either granted access to QBRs established byother processes or requests of the Exec (a name for the operatingsystem) to build a QBR with appropriate access to the QBR. The operatingsystem generates an address space asset for that process to use as itsQBR and thus keep the space available for the linked list which willdevelop. If the asset is filled, that is, no further space is availablefor references to queue banks which the process will need, the operationof the deposit instruction notifies the Exec via an interrupt. The Execmay determine that the process has failed, or the Exec may allocate morespace to the QBR and allow the process's deposit instruction to restart.

An example procedure with reference to these FIGS. 5A-C follows.

Again, the typical situation would avail a client process of anindentured QBR, which is illustrated here, but one could have aplurality or multiplicity of client processes employing a single sharedQBR if desired, with priority schemes and similar overlays also findinguse in such situations. However, here we show the preferred embodimentusage with a single client process and a single QBR.

The Client process 71 a in state 100 of FIG. 5A (deposit operation) hasa reference 711 a to a queue bank (QB α) 712 a which it needs torelinquish control of, temporarily or permanently (so another processmay access it for example, or because it needs to do something similarto another queue bank that it will do to this one later, or anotherexample). The client process 71 a communicates with its QBR through aQBM 72 a, requesting a token and relinquishing the queue bank 712 a tocontrol of the QBM. The QBM checks the header 73 a of the QBR 731 a anddetermines that the address n−1(a) is available to store the queue bankreference. Accordingly, it transfers the queue bank reference to thataddress. At that time it takes the indication of the next availableaddress, here “c” from n−1(a) and places it into the header, now shownin FIG. 5B as 731 b.

In state 200, illustrated in FIG. 5B (withdraw operation), the clientprocess 71 b submits the token n−1 712 b to the QBM 72 b when it wantsto restore visibility to the queue bank it stored in the QBR. It ispossible that (in other non-illustrated embodiments) some other processmay have given process 71 b the token n−1 to retrieve the queue bankfrom the QBR, but again, the preferred embodiment assumes that multipleprocesses may use a single QBR but they do not usually use the QBR topass queue banks among the multiple processes. Each process, typically,will deposit its queue bank in the QBR and then withdraw its own queuebank from the QBR.

It may be noted that the reference 711 a is similar to the reference 711b, but the client process can manage control over queue banks and tokenshowsoever is convenient in the embodiment being designed by a reader ofthis document.

In FIG. 5C (deposit operation), state 300 illustrates the exchange ofthe queue bank 712 c supplied by the client process 71 c for a tokensupplied by the QBM 72 c. The QBM determines the token to return byexamining the header 731 c of the QBR 73 c, which indicates that thefirst available location 79 c is at “f”. The QBM computes theappropriate token for location “f”, updates the header with the nextavailable slot pointed to from location “f”, and stores a reference tothe queue bank 712 c in location “f”. FIG. 5C is here to illustrate theendpoint of usage for the QBR, because at location “f” 79 c there Is azero (0) stored, indicating in the preferred embodiment, that there isno other available address after “f” which can be used. Consequently,after filling f with queue bank reference a 712 c, the QBM will nolonger accept queue banks because it will have no tokens to deliver inresponse to requests.

This situation can be handled in various ways. The system can generate anew QBR and assign it to the client, expand the existing QBR, or it cansimply force the client to wait. Refer to the description of use ofinstructions for the QBM above for more detail regarding how this couldbe accomplished.

The situation not described here may be one in which a bad token is heldby a process. In other words, one which does not match the allocatedspace for a Queue Bank Repository or one which is otherwise defective.Also, situations may exist where the QBM fails to return a token orqueue bank. All such situations should be treated as errors and theoperating system should handle them in accordance with normal errorprocessing. The process should also have error handling routines tohandle this kind of situation.

III. Application Example Example

Assume a number of processes request the transmittal of 6 messagesacross a communication network by enqueuing the messages to thecommunications process's outbound queue. Message 1 is directed todestination B, Message 2 is directed to Destination C, Message 3 isdirected to Destination A, Message 4 is directed to Destination D, andMessage 5 is directed to Destination C. The communications process sendsthe 6 messages. It must now await response from each destination foreach (group of) messages sent to the particular destination. Thecommunications process is awaiting a response or time-out from thetransmission. If the receiver acknowledges the message, thecommunications process may delete that message. If the receiver requestsa re-transmission of the message, the communications process canretransmit the message. The communications process has “sent” eachmessage, but it has not completely handled each message. Thecommunications process needs to hold these sent messages somewhere. Thecommunications process cannot predict Which Destination is going torespond next. The communications process would like to be able toretrieve the messages in any order. In this example, the communicationsprocess can put each sent message in a “waiting response” Queue BankRepository. It stores the received token for each message in a listassociated with each destination that owes a response. When adestination responds, with an acknowledgement for instance, thecommunications processor can retrieve the token associated with thedestination, execute a Withdraw from the “waiting response” QBR usingthe token for that destination. When the instruction provides theassociated queue bank of the message, the communications process candelete that message. If the destination responded with a re-transmitrequest, the communications process can use the token to retrieve theassociated queue bank of the message in the same way but afterretrieving, re-transmit the request instead of deleting it.

Summary Table of Differences Between OBRs and Queuing FEATUREDESCRIPTION QUEUING REPOSITORIES ITEM ADDED/REMOVED QUEUE BANK QUEUEBANK ORDER FIFO OR LIFO UNORDERED (any slot) SHARABLE USUALLY SHAREDUSUALLY PRIVATE REMOVAL INFORMATION CONTAINS QUEUE REPOSITORY ID (token)HEADER ACCESS QUEUE BANK HEADER: REPOSITORY: ENQUEUE DEPOSIT/WITHDRAWDEQUEUE ONLY INTERNAL LINKAGE HIDDEN AREA IN FRONT REPOSITORY IS THE OFQUEUE BANK USED LINKAGE- FOR LINKING LINKAGE IS ONLY FOR AVAILABLEENTRIES- ENTRIES IN USE (preferably) HAVE NO LINKAGE Internal structureof QBR is hidden from process using the QBR POSSIBLE NUMBER OF UNLIMITED(very large) FIXED NUMBER (large) ITEMS CASCADING: QUEUES FIXED (cancontain OF QUEUES OF QUEUES cascaded items) OF . . .

IV. Preferred Embodiment Inventive Process Described Stepwise

Refer now to FIG. 6 in which a flow chart 160 of a preferred embodimentof the invention is illustrated. First, refer to step 161 wherein acomputer system having a queue bank repository QBR running is waiting toreceive requests for deposit or withdraw. The QBR mechanism firstdetermines 161 a, based on the instruction executed by the requestingprocess, whether it is handling a deposit or withdraw request. If it isa deposit request, the next thing to be determined 162 is whether thereare enough resources available to store, in the QBR, the reference tothe proffered queue bank. Typically, a preferred embodiment QBR has onthe order of 2³⁰ tokens available and can handle any process requestsfor storage. However, should a process reach the end of the repository'sspace for storage of queue bank references, then ways can be created towork around that, or the process can simply wait for a token (andcorresponding space) to become available. Readers may create muchsmaller QBRs than are commonly used by the inventors and this situationmay be common in such environments. (It should be noted that in thepreferred embodiments a QBR always has space to retain the whole queuebank reference as it requires only one entry in the QBR.)

If the QBR has insufficient space, that is, no available entries, aroutine should be initiated 168 to logically extend the QBR, or to wait,if that is preferred. The routine preferably will be an operating system(Exec) feature, although if, when the QBR is initially set up, it iscreated with expansion capacity, a deposit instruction could be used toautomatically add available entries (by reallocating memory spaceavailable to extend the QBR space). To accommodate QBRs with varyingcapacity, the tokens should be of sufficient size to uniquely identifyall of the initially set up entry space and any potential expansionareas of the QBR.

It should be clear that a token value uniquely identifies an entry inthe queue bank repository.

In order to obtain adequate performance of the QBR mechanism, conversionof a token to and from its corresponding entry location must be ahigh-speed operation. In the preferred embodiment, the token is derivedfrom the entry location relative to the QBR header. Other embodimentscould use other mechanisms, such as a hash table lookup, as will beapparent to one skilled in this art.

If there is an available entry in the QBR, the proffered queue bankdeposit is accepted and placed 164 into the available entry and theclient process receives 165 a token identifying the entry. (It should benoted that the steps 164 and 165 are order independent, which is whythey are illustrated as shown. Either one could precede the other as maybe convenient.) The QBR header is updated 166 with the location of thenext available entry. In the preferred embodiment, the available entriesare kept in a linked list, so that the entry corresponding to the tokenbeing delivered contains the location of the next available entry, whichmay be zero, indicating there are insufficient resources to processadditional requests. The QBM should complete the storage of theproffered queue bank reference 167 at the token indicated entry. Thenthe computer system can again wait 161 for further withdraw and depositrequests.

On receipt 161/161 a of a withdraw request, the identity of orinformation in the token is scrutinized 163. If the token is valid, thequeue bank reference stored in the entry associated with that token isreturned 170, the returned queue bank is made visible in the client'saddress space and the token received 171. The pointer to the newlyavailable entry is now updated 172, preferably by placing the lastavailable entry location or pointer into the newly available entry. (Thenewly available entry is created by the return of the queue bank fromthe entry identified by the token). Then control is shifted back tomonitoring in step 161 again, for new requests for deposit and withdraw.(It should be noted that the steps 170 and 171 are order independent,which is why they are illustrated as shown. Either one could precede theother as may be convenient.)

If, in step 163, it was determined that the token was improper, errorhanding routines should be called and employed 173. The error handlingroutines may close down (disallow process) use of a QBR if desirable inthe particular implementation. A token can be found to be improperbecause it is not within a valid range, because an indicated entry doesnot have a valid queue bank reference, or because the QBR is notfunctioning.

V. Conclusion

What is taught is a new way to provide the capacity to offload dataresources from the management responsibility of software entities, whichare called clients, that do not tie up significant computer resourcesand enables transfer of control over memory without copying data.

The invention is described in detail above and is only limited in scopeby the following appended claims.

1-9. (canceled)
 10. A method of storing a queue bank descriptor from aclient process into a queue bank repository comprising: indicating thata client process needs to store a queue bank descriptor into said queuebank repository, providing to said client process a token having anindication of an entry address into which the queue bank descriptor isstored in said queue bank repository such that the client can laterretrieve the stored queue bank by returning said token to said queuebank repository, storing said queue bank descriptor into said entryaddress, and removing said queue bank from the visible address space ofthe client process, and wherein upon said return said queue bankrepository a next available entry address in said queue, bank repositorywill be undated using the entry address into which said queue bankdescriptor had been stored.
 11. The method of claim 10 furthercomprising, reading from a header in said queue bank repository saidnext available entry address location prior to providing said token tosaid client and wherein said storing step comprises storing said queuebank descriptor into a last available entry address location.
 12. Themethod of claim 10 further comprising manufacturing said token toinclude an indication of said last available entry address location intowhich said client queue bank descriptor was stored.
 13. The method ofclaim 10 further comprising manufacturing said token to include anindication of said last available entry address location into which saidclient queue bank descriptor was stored, or if the repository is full,providing an indication of fullness.
 14. The method of claim 10 furthercomprising manufacturing said token to include an indication of saidlast available entry address location into which said client queue bankdescriptor was stored, or if the repository is full, not providing anytoken until said repository has an available address entry.
 15. Themethod of claim 10 further comprising manufacturing said token toinclude an indication of said last available entry address location intowhich said client queue bank descriptor was stored, or if the repositoryis full, providing an interrupt to an operating system.
 16. The methodof claim 15 wherein said operating system provides for more availableentry address locations when it receives said interrupt.
 17. The methodof claim 10 further comprising manufacturing said token to include anindication of said last available entry address location into which saidclient queue bank descriptor was stored, or if the repository is full,opening a new space of entries via a call to an operating system, sothat said manufacturing of said token can be accomplished with anindication that said client queue bank descriptor was stored in said newspace.
 18. A method of retrieving a queue bank by a client process froma queue bank repository for storing queue bank descriptors comprising:providing a token to said queue bank repository by said client process,reading said token to determine an address containing a one of saidqueue bank descriptors by said queue bank repository, providing datafrom said address containing said queue bank descriptor to said clientprocess by said queue bank repository, and establishing said retrievedqueue bank in the visible address space of the client as specified bythe client process.
 19. A method for handling invalid attempts toretrieve a queue bank by a client process from a Queue Bank Repositoryfor storing queue bank descriptors, said method comprising: providing afalse token to said queue bank repository by a client process, readingsaid false token to determine an address containing said queue bankreference by said queue bank repository providing a status indicatingthat the token was not valid if no deposit currently exists at thattoken address.
 20. A system for handling a queue bank repository systemcomprising at least two methods, the first method, for storing a queuebank from a client process into a queue bank repository comprising:indicating that a client process needs to store a queue bank into saidqueue bank repository, providing to said client process a token havingan indication of an entry address into which the queue bank descriptoris stored in said queue bank repository such that the client can laterretrieve the stored queue bank, and storing said queue bank descriptorinto said entry address, and the second method, for retrieving a saidqueue bank that has been from a client process in a queue bankrepository comprising: providing a token to said queue bank repositoryby said client, reading said token to determine an address containingsaid queue bank descriptor by said queue bank repository, and providingdata from said address containing said queue bank to said client processby said queue bank repository.
 21. The system of claim 19, furthercomprising a method for handling invalid attempts to retrieve a queuebank by a client process from a Queue Bank Repository comprising:providing a false token to said queue bank repository by said client,reading said token to determine an address containing said queue bank bysaid queue bank repository, and providing a status indicating that thetoken was not valid.